This is related to feature enhancement requested here:
#2203

@lkuik can you elaborate a bit more about how you plan to use a package.vendor field?

My first thought is many packages aren't authored or maintained by a vendor, but instead by an individual, group of maintainers, project, etc. I took a brief look across different package registries and package formats (npm, pypi, gem, deb, rpm), and I'm not seeing consistent convention.

The tests are failing because because make needs run and the generated files commited.

@lkuik can you elaborate a bit more about how you plan to use a package.vendor field?

My first thought is many packages aren't authored or maintained by a vendor, but instead by an individual, group of maintainers, project, etc. I took a brief look across different package registries and package formats (npm, pypi, gem, deb, rpm), and I'm not seeing consistent convention.

That's a great point @ebeahan
I guess I was thinking more application than package in this context, and perhaps that was my mistake.
I didn't see anything for application ECS mapping so was thinking package was the more appropriate ECS field mapping to use.
So not just more open sourced focus (community maintained), but also thinking broader context of applications from security tools that can detect applications/packages too. So if that's not what this package fields for ECS was intended for may need to rethink where that would actually fit.

Just following up if you saw my post @ebeahan in regards to where I was coming from, was looking to get your thoughts based on that.

This PR is stale because it has been open for 60 days with no activity.